Processing extended transactions in a client-server system

ABSTRACT

Extended business transactions are processed in a client-server system in a manner which allows processing initiated by a client to be interrupted before the transaction is complete and later resumed by the same or another client from the point of interruption. This is achieved by storing state information indicative of the progress of the transaction in a repository in association with an end-user identifier. When the end-user communicates his identifier via a client to the server for a second time, processing of the transaction can be resumed on the basis of the stored state.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to the processing of extended transactionsin a client-server environment.

BACKGROUND OF THE INVENTION

A business transaction is a self-contained business deal, for example,buying a theatre ticket. Some business transactions are simple andshort-lived. However, many are not, involving multiple actions that takeplace over an extended period, such as selling a holiday or a house.Such transactions will be referred to as “extended transactions”.

Traditional transaction processing systems based on large databases andtelecommunications networks are very well established. Such systemsenable end-users to initiate and complete short business transactionsvia a terminal network with, for example, a bank, to make payments intoor out of a bank account or simply to make an enquiry as to the balance.Such transactions are usually relatively short lived (of the order ofminutes) and either complete or fail within that time span. Acommunication session is established for the duration of the transactionand, when it is finished, communication is terminated. There is noconcept of suspending the transaction indefinitely and resuming at alater time or date although, while a transaction is active, necessarystate information is maintained to enable progression of the transactionand to permit recovery in the event of failure.

Traditional transaction processing systems have been implemented notonly as mainframe data processor complexes with a network of linkedterminals, acting as input-output devices with no intelligence, but alsoas client-server (distributed) systems in which a limited amount of thedata processing may be done at a local client computer, which callsfurther large programs in a server computer to complete the processingaction. The client often handles input and output of data to the serverand includes the terminal which the end-user actually uses. It mayhandle aspects of data conversion and translation between interfaceswhich a simple terminal could not handle.

More recently, the Internet has allowed a massive amount of informationto be accessed by individual computer users connected by so-called webbrowsers to web servers maintained by information service providers.These web browsers are general purpose client computers designed inaccordance with established protocols, such as HTTP, to transferinformation in the format known as HTML. However, the HTTP protocol isstateless so that a web browser's communications with the web serverterminate after each HTML transfer and the server does not preserveknowledge of the previous connection. This does not lend itself,therefore, to transaction processing.

Nevertheless, various ways of maintaining or retrieving some stateinformation about the current progress of a transaction have beenimplemented in order to allow transaction processing to be performedover the Internet. State information may be hidden in HTML forms andpassed back and forth between client and server so that the server canassociate the new input from the client with a transaction whose stateit has saved. Another known system, provided by Netscape CommunicationsCorp. in connection with their Netscape Navigator browser system(“Netscape” is a trademark of Netscape Communications, Inc.) involvesthe use of what are known as “cookies”, which allow some stateinformation to be preserved by appending cookies to server responses.Another method, described in our publication pending European patentapplication no. 0812088 involves embedding state information in“continuations” (hyperlinks) returned by the server to a client.

However, these known ways of introducing state information only allowthe processing of a transaction to continue where the client retainsthis information from the server and is able to pass it back to resumethe transaction. It does not allow for the complete disconnection of aclient and loss of the relevant state information such as might occur ina long-running business transaction. Nor does it allow for resumption ofthe interrupted transaction from another client.

DISCLOSURE OF THE INVENTION

A method of processing several types of extended transaction for anend-user in a client-server data processing system including a serverand a plurality of clients, extended transactions being transactionsmade up of component transactional interactions with an end-user towardsa common goal the processing of which can be suspended for an indefiniteperiod and resumed at a later time, each client being capable ofestablishing communication with said server for processing said end-usertransactional interactions; the method comprising the steps in theserver of: initially receiving an end-user identifier from one of saidclients; presenting a menu of said several types of extended transactionto said client for selection; receiving a selection of an extendedtransaction from said client; commencing processing of said selectedextended transaction; storing state information indicative of theprogress of said selected transaction; associating said end-useridentifier with said state information for said selected transaction;ceasing processing of said selected transaction following cessation ofcommunication with said one client; following cessation of processing ofsaid transaction, receiving said end-user identifier for a second timefrom another of said clients; in response to receipt of said identifierfor a second time, presenting all current extended transactions for thatend-user to said other client for a second selection by said client ofone of said extended transactions; and in response to said secondselection, resuming processing of said transaction from a pointdetermined by said stored state information for the selectedtransaction.

According to a second aspect, the invention also provides a computerprogram for performing the above method according to the invention.

According to a third aspect, the invention also provides a server forprocessing several types of extended transaction for an end-user in aclient-server data processing system including a plurality of clients,extended transactions being transactions made up of componenttransactional interactions with an end-user towards a common goal theprocessing of which can be suspended for an indefinite period andresumed at a later time, each client being capable of establishingcommunication with said server for processing said end-usertransactional interactions; the server comprising: transactionprocessing means; and means for connecting clients to the transactionprocessing means to enable communication therebetween; the transactionprocessing means being responsive to a first communication from one ofsaid clients of an end-user identifier to present a menu of said severaltypes of extended transaction to said client for selection, and inresponse to selection by said client of an extended transaction to startprocessing the selected extended transaction and to generate stateinformation indicative of the progress of the selected extendedtransaction; the server further comprising a repository for storing saidtransaction state information in association with said end-useridentifier; the transaction processing means being responsive, followingcessation of communication with said one client to cease processing theselected transaction, and being responsive to receipt of said end useridentifier for a second time from another of said clients to present allcurrent extended transactions for that end-user to said other client fora second selection by said other client of one of said extendedtransactions; and in response to said second selection, resumingprocessing of said transaction from a point determined by said storedstate information for the selected transaction in said repository.

Thus, by using the end-user identifier, such as a name or password,previously started transactions of that end-user can be identified andprocessing resumed from a point indicated by the stored stateinformation in the repository. The stored state information maycorrespond to the state at the time communication between client andserver ceased or to a later state reached as a result of the transactionprocessing means continuing to process the transaction asynchronouslyuntil such time as further client input is required.

A major advantage of the invention is that it permits extendedtransactions to be resumed from a different client from the client whichinitiated the transaction. This corresponds to the real world in whichan end-user may be in a physically different location with differentequipment when wanting to resume the transaction.

The invention also allows end-users to work on multiple transactions. Inresponse to a client communicating the end-user identifier, the serverpresents all current transactions for that end-user to the client whichidentifies an end-user selected transaction to the server forprocessing.

Preferably, the association of stored state information with an end-useris achieved by the generation of a token for the selected extendedtransaction and then providing the token following the second selectionby the other client to enable resumption of processing of thattransaction from its stored state.

Additionally, as the extended transaction involves multiple interactionsbetween server and client and the client has no ability to store stateinformation, it is a preferred feature of the invention that a token isgenerated, uniquely identifying the transaction and also beingidentified with its state information. This token is passed back fromserver to client with a response requiring end-user interaction and thenpassed back to the server with the end-user response so that processingof the transaction is resumed from its current state, as defined by therespective state information.

In a further preferred embodiment, not only does the invention allowresumption of processing from another client but it also allows thatclient to be of a different type. To achieve this, the server providesinformation for sending to the client in client-neutral form and this islater converted to client specific form for presentation to the end-userby the new type of client.

The client neutral information can include both business data and ageneric display format name. In this case, the invention provides formapping the generic display format name into a client specific templatefor displaying said business data.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described, by way of example only,with reference to a preferred embodiment thereof, as illustrated in theaccompanying drawings, in which:

FIG. 1 is an block diagram of a server system for processing extendedtransactions in accordance with the present invention;

FIG. 2 shows one example of the system of FIG. 1 adapted for threespecific types of client;

FIG. 3 illustrates the contents of a homebase repository forming part ofthe system of FIG. 1; and

FIG. 4 is a flow diagram illustrating a method of processing extendedtransactions according to the invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

In FIG. 1 is shown a client-server system in which multiple clients 5communicate with an extended transaction managing server system 10 toexecute business transactions, initiated by an end user through one ofthe clients.

As will be discussed in more detail in relation to FIG. 2, the clientsmay be of various different types, including conventional web browsers,IBM 3270 terminals (“IBM” is a trademark of International BusinessMachines Corporation) and voice responsive devices.

A typical extended business transaction could be to obtain insurance byrequesting quotations, selecting the best one, receiving an acceptanceand invoice and making the final payment. The various stages of such atransaction could take place at different times and places and it may bemost convenient for the customer to use different clients to perform thedifferent stages of the transaction. For example, the customer mayoriginally request a quote from his web browser but subsequently ring anautomated call centre to take up a particular quotation. Payment may befrom another type of client again.

To support this application model, not only must the extendedtransaction manager be able to cope with input from different types ofclient but it must also provide a mechanism by which the customer canhook back into the same transaction regardless of which client he isusing. The system of FIG. 1 provides these facilities.

In the system of FIG. 1, every input from a client 5 to the extendedtransaction managing server 10 is treated as a request either for abusiness service or simply for delivery of a static page back to theclient to provide information to the user or to enable him to providefurther input.

These requests are initially routed to one of a number of catchers 20,each of which corresponds to a particular type of client. The catchers20 together with a listener 26, mapper 27 and responder 28 form the workinitiation portion of the server 10. The listener, mapper and responderform a common client-neutral section having no knowledge of the type ofclient and perform a standard set of steps regardless of the type ofclient originating the work. The catchers 20 and associated renderers50, however, are unique to particular types of clients. By splitting thework initiation portion in this way, the server design is madesufficiently flexible to permit the addition of further types of clientwithout a total redesign.

The basic function of the catchers 20, on receiving an input from aclient, is to extract the generic request name and any additional datafrom the client input and to pass this to a queue in the listener 26. Ifthe client has also provided an Application Interaction Token (AIT), oneof which is associated uniquely with every extended transaction, this isalso passed to the listener.

In the case of a web browser client, the client input is sent via a webserver (not shown for the generalised clients 5 of FIG. 1) whichrecognises a URL (Uniform Resource Locator) in the browser input as arequest name and passes the data over a Common Gateway interface (CGI)to one of the catchers 20 which is specific to a web browser client. Thecatcher converts the web based data, such as the URL, to a generic formof request and data and passes it to the listener 26.

The listener 26 processes its queue to route work requests to theappropriate server process. It does this by passing the generic requestname, any associated data and the AIT, if any, to the mapper 27. Themapper looks up the request name and returns a ‘type’ to the listenerindicating whether this is a business service request (BSR) or a requestfor page delivery to provide a response to the client. If an AIT issupplied with the request, the mapper validates it. If no AIT issupplied and the request name is recognised as the first of a newextended transaction, the mapper generates an AIT.

In accordance with the type returned by the mapper, the listener eitherpasses a BSR to a business logic manager (BLM) 29 or passes a pagedelivery request in the form of a canvas ID to a queue in responder 28.Each item on a responder queue represents a reply to a request. A canvasID or name identifies a generic type of canvas (or template) suitablefor presentation of information back to clients in response to theparticular request.

The responder 28 routes responses (in this case the canvas ID) to theappropriate catcher 20. This catcher passes the canvas ID to arespective client-specific renderer 50 which generates an actual canvas51 by combining a client-specific file 52, stored in a file store 53,with externally supplied data, if any. The canvas is returned to theappropriate catcher 20 and passed on to the specific client whichdisplays it to the user.

Initially, when a user wishes to initiate a new business transaction, heidentifies himself to the server via the appropriate client by supplyinghis name (ID) and optionally a password. As described above, the workinitiation portion of the server returns a canvas presenting a menu ofpossible extended transactions to the user. The user then selects one ofthe transactions and this selection is converted by the work initiationportion of the server first to a generic request name and then to abusiness service request to a business logic manager (BLM) 29.

The business logic manager 29 determines what action to take accordingto predefined rules for processing this type of extended transaction. Itdivides the BSR into a set of component business logic tasks (BLTs)which it then schedules to be carried out by a back-end transactionprocessing system 30, coordinating the tasks and the handling of theirresponses according to criteria defined by the rules. The system 30 maybe a conventional transaction processing system, such as the CICS systemfrom IBM (“CICS” is a trademark of International Business MachinesCorporation), to which has been added a mirror function 31 forscheduling the tasks. The BLTs, such as BLT 32, run as applications inthe CICS system and can call CICS functions over the CICS API.

The BLTs may obtain information from CICS resources and put the datainto an application scratchpad 40, over a special API for the extendedtransaction manager. This information may include state data for thetransaction, generated as it progresses through various stages.

For the first valid new request of an extended transaction, anapplication interaction service in the mapper generates the applicationinteraction token (AIT) which is unique to this instance of theparticular extended transaction and stores it, along with the genericrequest name and, optionally, user supplied data in a home baserepository 41. The AIT can be used as a key to access the further stateinformation in the scratchpad, if necessary.

When the BLT has finished, it returns control to the BLM 29. The BLMlooks at the response from the BLT and returns it to the responder 28 inclient-neutral form. The responder passes the generic response,including the name of a canvas, to the catcher 20 from which the requestoriginated. As described above for page delivery, the catcher passes thecanvas name to the respective renderer 50, which accesses a file 52 in afile store 53, to generate a client specific canvas for return to thecatcher 20. In the case of a web browser, the file may be an HTML page.

If the particular response to the client and end-user needs data fromthe BLT, this is obtained by the appropriate renderer 50 from thescratchpad 40 and also included in the file which is returned to thecatcher. The business data is client-neutral, consisting only ofdata-name value pairs. Finally, the catcher returns the response to theclient 5, which initiated the transaction.

As indicated above, the catcher/renderer listener/responder arrangementis designed to separate the business logic and the presentation (client)logic so that the business logic has no need to know the type of clientwith which it is communicating. This ensures that if the client-typechanges during the life of the interaction, the business logic is in noway affected.

The table constituting the home base 41 is shown in FIG. 3 and gives thefacility for switching clients within the course of an extendedtransaction by providing a repository for the current state of anyextended transaction belonging to an identified user. Thus, as can beseen in FIG. 3, each row of the home base consists of a unique token(AIT) for each extended transaction in the second column. Each AIT isassociated with a particular user, whose user ID is in the first column.Other columns contain the generic request ID and, optionally, data whichmay have been provided by the end user or by a previous BLT and also adisplayable extended transaction name. For some stages of the extendedtransaction, the data field may be blank because no user data wasrequired or returned. A user may also have more than one currenttransaction, as is shown for user ID 2 in the third row of the table.The request ID and data will change during the progress of the extendedtransaction to represent the current state of the transaction. In theinsurance example, they could initially represent an insurance quotationbut could later be updated to represent the selection and payment stagesof the transaction. The request ID will normally change in response to afurther input from the client but may, in some cases, be changed by theBLM.

For some extended transactions, where the state information is morecomplex, it may be stored in the scratchpad 40 and accessed by using theAIT as a key.

In the example of FIG. 2, a customer looking for a holiday package mayregister with a travel agent's extended transaction manager system froma home computer, connected as a web browser to the Internet. Thiscommunication is routed by a web server (not shown) over a commongateway interface to a CGI catcher 21 in the travel agent's system. Thecustomer is presented with information to enable her to make enquirieson various combinations of travel destinations, dates and hotels. Theinformation is converted for presentation to the customer's browser byHTML renderer 54. On completing this initial enquiry, the customerdisconnects but the state of the transaction is stored in or by way ofthe homebase.

In her lunch hour, the customer may visit the travel agent's office todiscuss the results of her enquiry and provisionally book one of theoffers. This is done from the travel agent's IBM 3270 terminal, which ispermanently on-line to the system and connected to 3270 catcher 23.Feedback from the system is converted to 3270 format by renderer 55. Thetransaction is resumed from the previous state in response to provisionof the customer's ID and presentation of her in-flight transactions.Confirmation is not immediately available so the customer terminates theconnection to suspend the transaction.

In the evening, she phones an automated voice-response service at thetravel agent's, identifies herself and is able to get confirmation ofher booking via voice catcher 24 and renderer 56.

In this scenario, the same customer interacts with the agent's systemvia three different clients to initiate and progress her businesstransaction. Note, however, that any of her accesses could have beenperformed from any of the clients in any order or from a single client.The invention allows continuation of the transaction from any clientafter lengthy periods of disconnection from the system betweeninteractions.

The operation of the system will now be described in more detail withreference to the flow diagram of FIG. 4.

When a user accesses the server through any client, in step 99, he willbe given the opportunity (step 100) to register (step 101), if a newuser. A user who is already registered identifies himself, in step 102,by supplying a name and password, customer number or similaridentification.

In step 103, the home base is checked, to see if the known user has any“in-flight” extended transactions, that is, existing but incompletetransactions which are currently suspended. If not, in step 104,a menuof available business transactions is presented to the user. The samemenu is also presented to a newly registered user. The user selects oneof these transactions and fills in any data fields which are thenrequired and the corresponding opening request ID and data are sent tothe appropriate catcher. After the request ID and data are converted togeneric form and passed to the listener and mapper, the unique AIT forthe newly started transaction is then generated by the mapper and storedin the home base, together with the associated request ID and any data(step 105).

If the user did have in-flight transactions, the system would instead,in step 106, display a menu of these transactions and give the user theoption of starting a new transaction (step 107), resuming an existingtransaction (step 108) or cancelling an existing transaction (step 109).Selecting the option of starting a new transaction, leads the userthrough steps 104 and 105 as described above.

In step 111, after generation of the AIT and of a home base entry instep 105, the initial request is passed, via the listener and mapper, asa business service request to the business logic manager 29 and thebusiness logic tasks 32 are started. These normally involve furtherinteraction with the user via the client. The AIT is passed to theclient from the server via the responder and catcher so that the clientcan continue the interaction from the current point in the transactionwithout having to retain any information itself as to the current stateof the transaction. The AIT is resent by the client to the catcher inthe next response which forms part of the same interaction.

If, in step 108, the user selects an existing transaction to resume, thehomebase entries for that user are scanned, in step 110, and the AIT forthe selected existing transaction is provided. Processing then resumes,in step 111, from the state stored in the homebase 41 and/or scratchpad40.

Whenever the business logic reaches a significant point in theprocessing of an extended transaction, for example, upon receipt of anew request from the client, it makes a call (step 112) to the home baseto update the record for that transaction with the appropriate requestID and data and, if required, stores additional state data in thescratchpad. The stored information is always that appropriate forresuming the transaction. Thus, when the user next accesses the systemthrough any client, provision of the AIT in step 110 enables thetransaction processing to be resumed from the stored state.

This allows the user to terminate further processing of the extendedtransaction from a particular client at any time and to resume from thesame point at a later time from either the original client or from acompletely different client. Irrespective of the clients, abilities todo so, state information about the transaction cannot be stored at theclient because the new access may be from a client which has notpreviously been associated with that transaction. In addition, a singleuser may have more than one ongoing transaction in the same system andmay want to be able to continue with any of them.

When an extended transaction is completed (step 113) or a decision ismade to cancel an existing transaction (step 109), the record of thetransaction is deleted from the home base, together with its AIT (step114). If the transaction is not completed, the client either proceedswith further processing from step 115 by returning to step 111 orterminates its interaction by disconnecting at step 116 to interrupt thetransaction at an intermediate state. Disconnection also takes place, instep 117, if, in step 109, the user decides not to cancel the existingtransaction. Processing can be resumed from step 100 at a later time bythe user providing his user id via any client.

What is claimed is:
 1. A method of processing several types of extendedtransaction for an end-user in a client-server data processing systemincluding a server and a plurality of clients, extended transactionsbeing transactions made up of component transactional interactions withan end-user towards a common goal the processing of which can besuspended for an indefinite period and resumed at a later time, eachclient being capable of establishing communication with said server forprocessing said end-user transactional interactions; the methodcomprising the steps in the server of: initially receiving an end-useridentifier from one of said clients; presenting a menu of said severaltypes of extended transaction to said client for selection; receiving aselection of an extended transaction from said client; commencingprocessing of said selected extended transaction; storing stateinformation indicative of the progress of said selected transaction;associating said end-user identifier with said state information forsaid selected transaction; ceasing processing of said selectedtransaction following cessation of communication with said one client;following cessation of processing of said transaction, receiving saidend-user identifier for a second time from another of said clients; inresponse to receipt of said identifier for a second time, presenting allcurrent extended transactions for that end-user to said other client fora second selection by said client of one of said extended transactions;and in response to said second selection, resuming processing of saidtransaction from a point determined by said stored state information forthe selected transaction.
 2. A method as claimed in claim 1 wherein theassociating step includes generating a token for the selected extendedtransaction uniquely identifying that transaction and also beingassociated with its state information, the method further including thestep of, following said second selection by said other client, providingthe token for the selected extended transaction to enable saidresumption of processing of that transaction from its stored state.
 3. Amethod as claimed in claim 2, including the further steps of, during anend-user transactional interaction, passing said token back to a clientwith a response requiring end-user interaction, and receiving saidend-user interactive response back from said client to said server withsaid token so that processing of that end-user transactional interactionis resumed from its current state.
 4. A method as claimed in claim 1 inwhich the client-server system includes first and second clients ofdifferent types, the method including the steps of the server providinginformation for sending to the client in client-neutral form andconverting said client-neutral information to the appropriate clientspecific form for presentation to said end-user by said respectiveclient.
 5. A server for processing several types of extended transactionfor an end-user in a client-server data processing system including aplurality of clients, extended transactions being transactions made upof component transactional interactions with an end-user towards acommon goal the processing of which can be suspended for an indefiniteperiod and resumed at a later time, each client being capable ofestablishing communication with said server for processing said end-usertransactional interactions; the server comprising: transactionprocessing means; and means for connecting clients to the transactionprocessing means to enable communication therebetween; the transactionprocessing means being responsive to a first communication from one ofsaid clients of an end-user identifier to present a menu of said severaltypes of extended transaction to said client for selection, and inresponse to selection by said client of an extended transaction to startprocessing the selected extended transaction and to generate stateinformation indicative of the progress of the selected extendedtransaction; the server further comprising a repository for storing saidtransaction state information in association with said end-useridentifier; the transaction processing means being responsive, followingcessation of communication with said one client to cease processing theselected transaction, and being responsive to receipt of said end useridentifier for a second time from another of said clients to present allcurrent extended transactions for that end-user to said other client fora second selection by said other client of one of said extendedtransactions; and in response to said second selection, resumingprocessing of said transaction from a point determined by said storedstate information for the selected transaction in said repository.
 6. Aserver as claimed in claim 5 for use in a system wherein the clientshave no ability to store state information; the server furtherincluding: means for generating a token uniquely identifying a selectedextended transaction and for storing said token in the repository inassociation with the transaction state information; and means forproviding the token for the selected extended transaction following saidsecond selection, to enable said resumption of processing of thattransaction from its stored state by the transaction processing means.7. A server as claimed in claim 6 including means for passing the tokenback from said server to the client, during an end-user transactionalinteraction, with a response requiring end-user interaction, and meansfor receiving an end-user interactive response back from said clientincluding said token so that processing of that end-user transactionalinteraction is resumed from its current state.
 8. A server as claimed inclaim 5 in which the server includes means for communicating output fromsaid transaction processing means to a client as information in clientneutral form, and output conversion means for converting said clientneutral information to the appropriate client specific form forpresentation to said end-user by said respective client, whereby clientsof different types may be accommodated.
 9. A server as claimed in claim8 in which said communicated client neutral information includes bothbusiness data and a generic display format name, said output conversionmeans including a rendering means to map said generic display formatname into a client specific template for displaying said business data.10. A server as claimed in claim 8 further including input conversionmeans for converting information in client specific form to informationin client neutral form; and work initiation means responsive to clientneutral information to map such information into requests forpresentation of pre-stored information to said client and requests fortransaction processing by said transaction processing means.
 11. Aserver as claimed in claim 10 in which the transaction processing meansincludes a business logic manager for breaking up a request fortransaction processing into a number of tasks and for scheduling thesetasks for processing, and a task processing means for processingindividual tasks.
 12. A server as claimed in claim 8 for use with atleast one web browser client, the client specific form for presentationto said end-user by the at least one web browser client being HTMLpages.
 13. A server as claimed in claim 12, for use also with at leastone dumb terminal client and one voice responsive client, said outputconversion means being capable of converting said client neutralinformation into output specific to a dumb terminal or voice responseunit as appropriate.
 14. A computer program product recorded on amedium, for performing a method of processing several types of extendedtransaction for an end-user in a client-server data processing systemincluding a server and a plurality of clients, extended transactionsbeing transactions made up of component transactional interactions withan end-user towards a common goal, the processing of which can besuspended for an indefinite period and resumed at a later time, eachclient being capable of establishing communication with said server forprocessing said end-user transactional interactions; the methodcomprising the steps in the server of: initially receiving an end-useridentifier from one of said clients; presenting a menu of said severaltypes of extended transaction to said client for selection; receiving aselection of an extended transaction from said client; commencingprocessing of said selected extended transaction; storing stateinformation indicative of the progress of said selected transaction;associating said end-user identifier with said state information forsaid selected transaction; ceasing processing of said selectedtransaction following cessation of communication with said one client;following cessation of processing of said transaction, receiving saidend-user identifier for a second time from another of said clients; inresponse to receipt of said identifier for a second time, presenting allcurrent extended transactions for that end-user to said other client fora second selection (107, 108) by said other client of one of saidextended transactions; and in response to said second selection,resuming processing of said transaction from a point determined by saidstored state information for the selected transaction.
 15. A method ofprocessing several types of extended transaction for an end-user in aclient-server data processing system including a server and a pluralityof clients including first and second clients of different types,extended transactions being transactions made up of componenttransactional interactions with an end-user towards a common goal theprocessing of which can be suspended for an indefinite period andresumed at a later time, each client being capable of establishingcommunication with said server for processing said end-usertransactional interactions; the method comprising the steps in theserver of: initially receiving an end-user identifier from said firstclient; presenting a menu of said several types of extended transactionto said client for selection; receiving a selection of an extendedtransaction from said first client; commencing processing of saidselected extended transaction; storing state information indicative ofthe progress of said selected transaction; associating said end-useridentifier with said state information for said selected transaction;ceasing processing of said selected transaction following cessation ofcommunication with said first client; following cessation of processingof said transaction, receiving said end-user identifier for a secondtime from said second client; in response to receipt of said identifierfor a second time, presenting all current extended transactions for thatend-user to said second client for a second selection by said secondclient of one of said extended transactions; and in response to saidsecond selection, resuming processing of said transaction from a pointdetermined by said stored state information for the selectedtransaction; wherein the server provides information for sending to anyof said clients in client-neutral form and converts said client-neutralinformation to the appropriate client specific form for presentation tosaid end-user by said respective client.
 16. A method as claimed inclaim 15 wherein the associating step includes generating a token forthe selected extended transaction uniquely identifying that transactionand also being associated with its state information, the method furtherincluding the step of, following said second selection by said otherclient, providing the token for the selected extended transaction toenable said resumption of processing of that transaction from its storedstate.
 17. A method as claimed in claim 16, including the further stepsof, during an end-user transactional interaction, passing said tokenback to a client with a response requiring end-user interaction, andreceiving said end-user interactive response back from said client tosaid server with said token so that processing of that end-usertransactional interaction is resumed from its current state.
 18. Aserver for processing several types of extended transaction for anend-user in a client-server data processing system including first andsecond clients of different types, extended transactions beingtransactions made up of component transactional interactions with anend-user towards a common goal the processing of which can be suspendedfor an indefinite period and resumed at a later time, each client beingcapable of establishing communication with said server for processingsaid end-user transactional interactions; the server comprising:transaction processing means; and means for connecting said clients tothe transaction processing means to enable communication therebetween;the transaction processing means being responsive to a firstcommunication from said first client of an end-user identifier topresent a menu of said several types of extended transaction to saidfirst client for selection, and in response to selection by said firstclient of an extended transaction to start processing the selectedextended transaction and to generate state information indicative of theprogress of the selected extended transaction; the server furthercomprising a repository for storing said transaction state informationin association with said end-user identifier; the transaction processingmeans being responsive, following cessation of communication with saidfirst client to cease processing the selected transaction, and beingresponsive to receipt of said end user identifier for a second time fromsaid second client to present all current extended transactions for thatend-user to said second client for a second selection by said secondclient of one of said extended transaction, and, in response to saidsecond selection, resuming processing of said transaction from a pointdetermined by said stored state information for the selected transactionin said repository; said server further including means forcommunicating output from said transaction processing means to eitherclient as information in client neutral form, and output conversionmeans for converting said client neutral information to the appropriateclient specific form for presentation to said end-user by saidrespective client, whereby clients of different types may beaccommodated.
 19. A server as claimed in claim 18 for use in a systemwherein the clients have no ability to store state information; theserver further including: means for generating a token uniquelyidentifying a selected extended transaction and for storing said tokenin the repository in association with the transaction state information;and means for providing the token for the selected extended transactionfollowing said second selection, to enable said resumption of processingof that transaction from its stored state by the transaction processingmeans.
 20. A server as claimed in claim 19 including means for passingthe token back from said server to the client, during an end-usertransactional interaction, with a response requiring end-userinteraction, and means for receiving an end-user interactive responseback from said client including said token so that processing of thatend-user transactional interaction is resumed from its current state.21. A server as claimed in claim 18 in which said communicated clientneutral information includes both business data and a generic displayformat name, said output conversion means including a rendering means tomap said generic display format name into a client specific template fordisplaying said business data.
 22. A server as claimed in claim 18further including input conversion means for converting information inclient specific form to information in client neutral form; and workinitiation means responsive to client neutral information to map suchinformation into requests for presentation of pre-stored information tosaid client and requests for transaction processing by said transactionprocessing means.
 23. A server as claimed in claim 22 in which thetransaction processing means includes a business logic manager forbreaking up a request for transaction processing into a number of tasksand for scheduling these tasks for processing, and a task processingmeans for processing individual tasks.
 24. A server as claimed in claim18 for use with at least one web browser client, the client specificform for presentation to said end-user by the at least one web browserclient being HTML pages.
 25. A server as claimed in claim 24, for usealso with at least one dumb terminal client and one voice responsiveclient, said output conversion means being capable of converting saidclient neutral information into output specific to a dumb terminal orvoice response unit as appropriate.
 26. A computer program productrecorded on a medium, for performing a method of processing severaltypes of extended transaction for an end-user in a client-server dataprocessing system including a server and a plurality of clientsincluding first and second clients of different types, extendedtransactions being transactions made up of component transactionalinteractions with an end-user towards a common goal, the processing ofwhich can be suspended for an indefinite period and resumed at a latertime, each client being capable of establishing communication with saidserver for processing said end-user transactional interactions; themethod comprising the steps in the server of: initially receiving anend-user identifier from said first client; presenting a menu of saidseveral types of extended transaction to said first client forselection; receiving a selection of an extended transaction from saidfirst client; commencing processing of said selected extendedtransaction; storing state information indicative of the progress ofsaid selected transaction; associating said end-user identifier withsaid state information for said selected transaction; ceasing processingof said selected transaction following cessation of communication withsaid first client; following cessation of processing of saidtransaction, receiving said end-user identifier for a second time fromsaid second client; in response to receipt of said identifier for asecond time, presenting all current extended transactions for thatend-user to said second client for a second selection by said secondclient of one of said extended transactions; and in response to saidsecond selection, resuming processing of said transaction from a pointdetermined by said stored state information for the selectedtransaction; wherein the server provides information for sending to anyof said clients in client-neutral form and converts said client-neutralinformation to the appropriate client specific form for presentation tosaid end-user by said respective client.